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Abstract 

A  database  is  usually  expected  to  give  correct  and  complete  answers  to  queries. 
However,  some  applications  take  confidentiality  to  an  extreme  and  require  the 
database  to  deceive  some  users  by  supplying  incorrect  answers.  This  paper  examines 
these  requirements  and  studies  the  effectiveness  of  three  database  security  techniques 
in  this  area. 
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lies.  Damned  lies  and  Databases 


LLitrodBcfta 

A  database  management  sys^^m  OBSiS)  provides  services  for  storing  and  retrieving 
information  in  a  way  wbich  is  lo^eally  independent  of  the  physical  storage  stmctnres 
employed.  In  a  secure  database,  where  coniidentialify  is  of  prime  concern,  the  stored 
information  is  ascribed  variotu  dassiBcations  and  there  is  a  requirement  that  no  user,  or 
process  ronning  on  their  behalf,  may  obtain  information  nnless  their  clearance  dominates  its 
classification. 

In  addition  to  ensuring  that  information  is  not  directly  given  to  users  with  insufficient 
clearances,  the  DBMS,  like  any  other  secnre  system,  mnst  ensure  that  dassified  information 
is  not  leaked  indirectly.  HighV  dassified  information  could  be  encoded,  using  the  fadlities 
of  the  DBMS,  in  a  way  which  makes  it  appear  to  be  of  lower  classification.  Users  with  low 
clearances  who  know  the  encoding  sdieme  would  then  receWe  highly  classified  information 
from  a  Trojan  Horse  operating  at  the  hi^er  levd. 

An  additional  requirement  is  that  the  database  schema  mnst  be  inferentially  secure 
(MorgenstemSS],  that  is  highly  dassified  information  can  never  be  inferred  from  lowly 
classified  information.  Solving  this  inference  problem,  and  the  allied  aggregation  problem, 
is  the  concern  of  the  database  design  process,  and  has  been  dealt  with  elsewhere  [LuntSS], 

So  it  is  necessary  for  both  the  design  of  the  database  schema  and  the  DBMS  to  be  secure. 
However,  confidentiality  is  not  the  only  security  problem.  Integrity  is  an  important  concern 
and  is  partly  addressed  through  the  use  of  constraints  in  the  database  schema.  The  use  of 
constraints  can  be  likened  to  the  use  of  defensive  programming  techniques.  They  are  tlie  first 
line  of  defence  for  integrify  as  they  ensure  the  database  is  always  in  a  valid  state,  though  they 
do  not  guarantee  that  this  state  is  appropriate  (TenyS9].  By  offering  constraint  enforcement  as 
a  general  service,  a  DBMS  makes  the  implementation  of  robust  applications  more  cost 
effective. 

One  important  reason  for  using  a  DBMS  to  store  information  is,  therefore,  that  it  helps  preserve 
the  integrity  of  the  information  it  holds.  However,  there  are  applications  where  different  users 
are  required  to  have  views  of  the  same  information  which,  while  they  are  individually  self- 
consistent,  actually  contradict  each  other.  In  particular,  a  database  can  be  required  to  lie  about 
the  true  state  of  the  world  to  some  users.  At  first  sight  this  appears  to  be  a  requirement  for 
databases  which  have  no  integrity,  but  actually  the  database  must  lie  consistently  and 
properly,  and  the  integrity  of  the  lies  is  extremely  important. 

Most  of  the  examples  of  this  kind  arise  in  the  military  intelligence  arena,  however  a  good 
example  occurs  in  the  medical  worldl.  On  reaching  a  conclusion  about  a  patient’s  condition,  a 
Doctor  might  tell  the  patient  they  have  Bronchitis  and  send  them  off  for  hospital  tests.  However, 
the  Doctor  tells  the  hospital  that  lung  cancer  is  suspected.  The  deception  must  be  maintained  to 
avoid  premature  concern  in  the  patient  and  embarrassment  to  the  Doctor. 

This  paper  examines  some  of  the  requirements  for  databases  which  are  intended  to  deceive 
some  users  and  compares  the  effectiveness  of  three  secure  database  implementation 
techniques  in  this  kind  of  application.  Section  two  introduces  some  example  requliements  for 
deceptive  databases  while  section  three  informally  presents  security  models  for  three 
implementation  techniques.  In  section  four,  the  suitability  of  the  three  techniques  is  examined 
with  respect  to  applications  which  deceive  with  integrity.  Finally,  section  five  summarises  the 
position. 


iThis  example  was  given  by  John  Dobson  at  the  1990  IFIP  WG11.3  Database  Security 
Workshop  to  illustrate  a  point  from  [Martin90). 
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Hiere  sre  requirements  for  virioiis  different  fdnds  of  ceoepticn  in  a  secure  database.  Ibese 
range  from  VhHe  lies',  wbicii  seek  to  prciect  tie  innoeeoi  fioja  fee  sordid  truth,  to  tfce  reaiiy 
deceitful  lies  which  aim  to  mislead  and  conupt.  'This  section  discusses  the  various 
pos^iliiies  and  fjostrates  them  with  examples,  but  iirst  it  considers  what  the  responses  of  an 
honest  database  should  be. 

2.1  Honest  Henlies 

IVpically,  a  database  is  interrogated  by  requests  that  ask  for  all  iribrmation  meeting  certain 
criteria,  such  as  liow  far  is  USS  Kebula  from  Earth?*.  To  sudr  questions  an  honest  secure 
database  would  reply  either  with  the  required  information,  or  with  notiHcaticn  that  the  user  has 
insuflicient  clearance  to  calculate  the  result,  or  with  notification  that  the  resulting 
information  itself  is  too  hi^ly  classined,  or  perhaps  some  combination  of  all  three. 

The  following  example  is  given  to  illustrate  these  three  kinds  of  honest  response.  The  notation 
of  the  fact  model  is  used  (SowerbuUsSO],  and  the  facts,  question  and  replies  are  summarised  in 
figure  2.1. 


The  facts. 

Unclassified:  Nebuia  is  going  somewhere 
Confidential:  IJcjala  is  going  to  Earth 
Secret:  Hebula  is  42 .S9  parsecs  from  Eertb 

The  question. 

'How  far  is  Nebula  from  Earihr 
The  answers. 

Unclassified:  you  have  inrufficient  clearance  to  calculate  answer 
Confidential:  you  are  not  cleared  to  know  the  distance 
Secret:  42.59 

Figure  2.1:  Example  facts  and  honest  answers  to  a  question. 

So  USS  Nebula  is  going  to  Earth  and  is  currently  at  a  distance  of  42.59  parsecs,  and  this 
information  is  Secret.  However,  the  fact  that  Nebula  is  going  somewhere  is  Unclassified  and 
that  its  destination  is  Earth  is  Confidential.  Users  who  ask  "how  far  is  USS  Nebula  from 
Earth?"  will  get  different  answers  depending  on  their  clearance. 

A  user  with  a  clearance  of  Unclassified  would  get  the  answer  "you  have  insufficient 
clearances  to  calculate  the  answer".  This  is  because  tne  DBMS  roust  check  that  Nebula  is 
actually  going  to  Earth,  but  it  fmds  that  a  Confidential  fact  must  be  examined  to  ascertain 
whether  this  is  true.  Therefore  the  reply  cannot  be  "Nebula  is  not  going  to  Earth"  because  it 
might  be,  so  the  DBMS  gives  the  non-committal,  but  truthful,  reply  which  essentially  says  it 
doesn't  know  (at  that  level  of  clearance).  Note  that  the  same  answer  would  be  received  if  the 
Unclassified  user  asked  "how  far  is  USS  Nebula  from  Vulcan?". 

A  Confidential  user  would  receive  "you  are  not  cleared  to  know  the  distance".  This  is  on  the 
basis  that  the  DBMS  can  tell  that  Nebula  is  going  to  Earth,  but  when  it  goes  to  find  out  the 
distance  it  discovers  the  user  is  not  cleared  to  see  it.  Thus  the  DBMS  is  able  to  give  a  reply 
which  confirms  that  the  Nebula  is  heading  for  Earth,  but  the  actual  distance  cannot  be 
revealed.  Again  this  is  an  honest  reply,  and  is  more  detailed  than  that  given  to  the 
Unclassified  user,  but  it  is  not  the  complete  answer. 

A  Secret  user  obviously  gets  the  answer  "42.59"  which  is  the  whole  truth.  This  does  imply  the 
fact  that  Nebula  is  going  to  Earth,  but  this  fact  .'s  Oi  ly  Confidential  and  therefore  no  leak  has 
occurred. 
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Research  has  shown  that  Photon  Torpedoes,  carried  all  Federation  Starships,  may  be 
hazardous  to  the  health  of  the  crew.  However,  to  avoid  lowering  morale  it  is  necessary  not  only 
to  keep  the  details  secret  but  also  to  classify  the  very  existence  of  the  information.  Anyone 
without  the  appropriate  clearances  who  asks  about  the  health  hazards  of  Photon  Torpedoes  will 
be  told  'there  is  no  information  of  that  kind*. 

An  example  of  this  is  shown,  in  Figure  2.2.  The  database 'deceives  Unclassified  users,  by 
claiming  that  no  such  information  is  stored.  Confidential  users  get  an  honest  answer,  to  the 
effect  that  there  is  no  information  of  that  kind  available  to  them  but  there  is  information  which 
ihey  cannot  see.  Secret  users  are  told  that  the  information  does  exist,  but  they  are  not  allowed  to 
know  the  details.  Only  Top  Secret  users  get  the  complete  truth. 

The  facts. 

UnclassiHed 
Confidential 
Secret: 

Top  Secret: 

The  question. 

"How  much  radiation  does  the  Mk4  torpedo  emit?” 

The  answers. 

Unclassified:  there  is  nothing  about  radiation  from  MK4  torpedos 

Confidential;  if  that  information  exists,  you  cannot  see  it 

Secret:  you  are  not  cleared  to  know  the  radiation  output 

Top  Secret:  94.8 

Figure  2.2:  Example  of  denying  the  existence  of  information. 

Note  that  the  reply  to  Unclassified  users  categorically  denies  the  existence  of  the  information, 
which  is  a  complete  lie,  whereas  Confidential  and  Secret  users  receive  truthful,  but  incomplete, 
answers. 


The  invasion  of  Romulan  space  by  the  Federation  needs  to  be  a  well  kept  secret,  since  success 
relies  on  complete  surprise.  So  when  USS  Constitution  is  loaded  with  invasion  troops  and  sent 
to  Romulus,  a  cover  story  has  to  be  invented  to  avoid  suspicion. 

The  facts. 

Unclassified;  Constitution  is  going  to  Romulus 
Confidentia':  Constitution  has  a  covert  mission 
Unclassified:  Constituuon  is  going  to  Romulus  to  f  deliver  aid  'j 
Secret:  1  invade  ) 

The  question. 

"Why  is  Constitution  going  to  Romulus?" 

The  answers. 

Unclassified:  to  deliver  aid 

Confidential.  low  users  think  its  to  deliver  aid,  but  its  really  something  covert 

Secret’ _ low  users  think  its  to  deliver  aid,  but  really  its  to  invade _ 

Figure  2.3:  Example  of  a  cover  story. 


nothing  is  known 

there  is  some  Secret  information 

there  is  data  about  radiation  from  the  Mk4  torpedo 

Mk4  torpedo  emits  24.8  femtoUrgs  per  second 


Thus  the  general  public  are  told  that  Constituiian  is  on  a  mercy  mission  to  deliver  aid,  while 
highly  cleared  users  are  told  of  its  real  purpose.  It  is  possible  that  there  are  some  users  who 
know  the  mission  is  covert  and  that  a  cover  story  has  been  created,  but  th^  cannot  find  out 
details  of  the  real  mission.  Figure  2.3  shows  the  example,  with  the  cover  story  shown  by 
enclosing  the  different  versions  in  brackets.  This  is~to  emphasise  the  difference  between 
having  two  contradictory  facts  and  having  a  cover  story. 

In  this  example,  a  Starship  can  be  heading  to  only  one  destination  at  any  one  time  and  this  can 
only  be  for  one  reason.  If  the  cover  story  was  simply  given  as  an  additional  fact  at  the  Secret 
level,  as  in  Figure  2.4,  this  would  contradict  the  Unclassified  fact.  This  contra(hction  violates 
the  integrity  constrmnt  of  rmique  destination  end  purpose  per  ship. 

Thus  in  figure  2.3  the  notation  shows  that  the  Constitution  is  going  to  Eomulus  to  invade,  and 
this  is  Secret  It  also  says  that  a  cover  story  exists,  whirit  cart  be  seen  by  Unclassified  users. 
The  story  is  that  the  Constituticn  is  going  to  Bomulus  to  deliver  aid.  By  contrast  figure  2.4 
shows  the  Constitution  is  going  to  Romulus  to  invade  and  deliver  aid.  There  is  no  information 
available  to  indicate  that  the  Unclassified  fact  represents  a  cover  story,  since  it  may  simply  be 
that  inconsistent  data  has  been  entered. 


Unclassified:  Constitution  is  going  to  Romule-  to  deliver  aid 
Secret:  Cfinstitutian  is  going  to  Romulus  tojpyade_ 

Figure  2.4:  Facts  which  violate  integrity. 

So  the  integrity  constraint  which  insists  each  ship  has  a  imique  destination  and  purpose  is 
important.  Without  it  an  errant  user  or  application  software  would  be  able  to  send  Constitution 
to  Romulus  for  refueling  at  the  same  time  as  it  is  going  to  invade  (or  rather  deliver  aid  if  you 
are  not  cleared  to  Secret).  The  use  of  weakened  forms  of  integrity,  such  as  Polyinstantiation 
Integrity  (DenningSS],  go  some  way  to  avoiding  this  problem,  but  these  do  not  stop  an  errant 
program  at  a  different  security  level  entering  the  contradiction. 

24  Secrecy  about  Changes 

Eventually,  when  the  Constitution  reaches  Romulus,  the  cover  story  is  revealed,  but  later  the 
Enterprise  heads  for  Romulus  to  support  the  ill  fated  invasion.  This  is  common  knowledge, 
however,  on  route  the  Enterprise  falls  prey  to  a  previously  unencountered  life  form.  Back  at 
HQ,  intelligence  sources  realise  that  Enterprise  isn’t  going  to  make  it  to  the  battle.  However, 
this  information  must  be  kept  Secret  since  the  Romulans  are  currently  falling  back  and  the 
Federation  troops  are  pressing  forward,  all  because  they  think  the  Enterprise  is  coming 


The  facts. 

Unclassified:  Entemrise  is  eoine  to  Romulus 
Unclassified:  Enterprise  vrill  reach  Romulus  in 

fihiair 

Secret: 

The  question. 

"When  will  Enterprise  reach  Romulus?" 

The  answers. 

Unclassified:  Ihour 

Secret:  low  users  think  its  1  hour,  but  really  its  1  week  i 

Figure  2.5:  Example  of  secrecy  about  changes. 


This  example  is  just  like  a  cover  story,  though  it  arises  in  a  different  way,  and  is  shown  in 
Figure  2.5.  As  far  as  the  Unclassified  Federation  troops  and  any  eavesdropping  Romulans  are 
concerned,  the  Enterprise  is  about  to  arrive.  However,  the  commanders  know  that  it  has  been 
seriously  delayed  and  can  make  suitable  plans. 
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The  difference  between  this  kind  of  example  and  cover  stories  is  that  here  the  Unclassified  fact 
started  off  as  the  truth.  Only  later  did  the  truth  change  to  a  highly  classified  fact  and  the  low 
information  became  a  cover  story.  With  a  cover  story,  the  truth  is  initially  highly  classified 
and  a  misleading  version  is  deliberately  entered  with  a  lower  clasafication. 


The  facts. 

Unclassified: 

Entemrise  is  going  to  Romulus 

Secret  (Tactical): 

Enterprise  will  reach  Romulus  in 

f  1,084  WfiSks  1 

Secret  (Strategic): 

1^1  we^lc  J 

The  question. 

"When  will  Enterprise  reach  Romulus?" 

The  answers. 

Unclassified: 

you  are  not  cleared  to  know 

Secret  (Tacfical): 

1.084  weeks 

Secret  (Strategic): 

Iweek 

Figure  2.6:  Example  of  a  precis. 


The  example  shown  in  Figure  2.5  gives  different  answers  depending  on  the  user's  clearance, 
though  it  is  also  passible  that  the  answer  could  depend  on  some  other  attribute  of  the  user,  such 
as  their  role.  This  is  useful  if  the  requirement  is  to  hide  changes  which  occur  frequently,  as  it 
can  be  used  to  present  certain  users  with  a  precis  of  some  information.  This  kind  of  "white  lie" 
is  quite  different  to  a  cover  story,  since  it  can  actually  be  beneficial  because  it  hides  rapidly 
changing  irrelevant  detail 

Figure  2.6  gives  an  example  of  a  prdcis  which  is  based  on  whether  the  user  is  playing  a 
Tactical  or  Strategic  role.  The  tactical  information  is  accurati-  but  will  be  changing  rapidly, 
though  most  changes  will  be  small  and  irrelevant  to  the  Strategic  user  who  wants  a  more  global 
picture  Obviously  some  integrify  constraints  would  be  required  to  ensure  that  the  Strategic 
picture  does  not  become  too  out  of  line  with  the  Tactical  information,  but  this  concern  is  not 
addressed  here. 

In  this  example,  the  Secret  users  ask  the  same  question  but  receive  a  reply  which  depends  on 
their  role  Although  they  need  not  know  of  the  other's  existence,  it  is  not  of  paramount 
importance  to  keep  the  othe>’  hidden.  This  differs  from  cover  stories  where  hiding  the  existence 
of  a  cover  can  be  vital. 

A  problem  that  occurs  with  rapidly  changing  information  concerns  the  ability  to  serialise 
concurrent  transactions.  From  an  integrity  point  of  view  it  is  essential  that  all  concurrent 
execution  of  transactions  can  be  seen  as  some  serial  execution  of  the  transactions.  Generally, 
schemes  which  ensure  this  are  the  basis  for  covert  channels  in  a  secure  DBMS,  but  proposals 
have  been  made  for  secure  serialisation  [KeefeSOl.  These  however  are  prone  to  availability 
problems,  whereby  a  highly  cleared  user  wishing  to  obtain  a  consistent  picture  of  lowly 
classified  information  may  repeatedly  be  rolled-back  because  the  low  information  keeps 
changing.  The  use  of  a  prdcis  would  reduce  the  frequency  of  changes  and  make  it  more  likely 
that  the  high  users  could  complete  their  work. 


In  this  section,  three  techniques  for  database  security  are  described.  Rather  than  describe  them 
in  terms  of  a  data  model  and  argue  that  they  are  secure,  a  security  model  is  used  to  model  them 
and  this  is  related  to  the  relational  data  model  as  a  justification  of  the  model's 
appropriateness.  The  use  of  a  model  to  describe  the  way  in  which  the  techniques  work  is 
necessaiy  to  enable  the  confidentiality  controls,  on  which  the  integrity  of  the  deceptions  rely,  to 
be  clearly  identified.  Also  it  avoids  describing  specific  secure  DBMSs,  which  necessarily 


introduce  additional  constraints  and  features  which  are  not  directly  relevant  to  this 
discussion. 

A  simple  Bell-LaPadula  style  of  security  model  [861174]  is  used.  The  important  aspects  of  this 
model  are  that: 

1) .  Objects  are  classified  containers  and  a  policy  of  "no  flows  down"  is  enforced; 

2) .  Ko  flows  down  is  not  violated  by  transitions  which  involve  a  "pure  write"  or  "append”  kind 
of  alteration  of  high  Objects  while  also  observing  or  modifying  low  Objects; 

3) .  Objects  may  be  created  and  destroyed  and  an  Object's  classification  may  be  raised  at  any 
time,  though  an  addressing  Hierarchy  is  employed  to  ensure  that  no  covert  channels  arise 
through  these  operations; 

4) .  An  Object's  classification  may  be  lowered  at  any  time,  subject  to  the  controls  of  the 
Hierarchy  and  as  long  as  its  original  contents  are  completely  destroyed  and  the  new 
classiflcation  dominates  the  sources  of  the  new  contents; 

5) .  The  roots  of  the  Hierarchy  are  either  fixed  or  their  creation  and  destruction  is  subject  to 
some  unspecified  control  which  avoids  the  potential  covert  channels. 

The  models  presented  here  are  abstract  interpretations  and  do  not  necessarily  reflect  how  such 
databases  are  implemented  in  practice.  Also,  it  is  likely  that  more  constraints  will  be  imposed 
on  the  database  by  implementation  considerations. 

8.1  Palviiistantiatiga 

fhc  most  widely  proposed  and  used  technique  for  providing  secure  DBMSs  is  called 
Polyinstantiation^  [OenningS?].  Other  flavours  of  Polyinstantiation  have  been  proposed 
[HaighSOl  [Jajodia90),  but  all  arc  covered  by  the  model  given  here. 

There  arc  two  kinds  of  Object  in  this  model:  collections  of  facts  and  schema  details.  A 
collection  of  facts  has  a  classification,  which  applies  to  all  facts  in  the  collection.  The 
Collection  Objects  can  only  be  accessed  through  the  Schema  Object  that  describes  the  facts  that 
they  contain.  The  classification  of  a  Schema  Object  is  always  dominated  by  the  classification 
of  any  Collection  that  it  refers  to. 

The  Schema  Objects  correspond  to  tables  in  the  relational  model.  The  Collection  Objects 
contain  single  level  subsets  of  the  table.  If  data  is  classified  at  the  row  level,  all  rows  of  the 
same  classification  are  stored  in  one  Collection  Object.  If  fields  are  separately  labelled,  data 
from  different  Collections  must  be  joined  in  some  way,  [DenningSTl  [JajodiaSO],  to  reconstruct 
the  multi-level  information. 

A  new  fact  ran  be  added  to  the  database  by  adding  it  to  one  of  the  collections.  This  alters  one  of 
the  Collection  Objects  and  so  the  user  must  have  a  clearance  which  is  dominated  by  the 
classification  of  the  collection.  The  user's  clearance  must  also  dominate  the  classification  of 
the  Schema  Object  in  order  that  they  can  "address"  the  Collection  Object. 

Although  this  model  allows  a  user  to  overclassify  a  fact,  by  inserting  it  into  a  Collection  Object 
whose  clearance  strictly  dominates  their  clearance,  it  is  unlikely  to  be  implemented  because  of 


tPolyinstantiation  refers  to  the  simultaneous  existence  of  multiple  objects  with  the  same  name 
that  are  distinguished  by  their  classification  [DenningS?].  Allowing  polyinstantiation  is  one 
technique  for  closing  covert  channels  that  arise  when  creating  and  deleting  objects. 
Polyinstantiation  is  not  an  inevitable  consequence  of  multi-level  security. 
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the  difRculty  in  providing  a  "pure”  write  which  alters  just  part  of  an  Object.  Thus  in  practice  it 
is  likely  that  a  user  will  only  be  able  to  insert  a  fact  at  their  own  level. 

Similarly,  a  user  can  delete  a  fact  which  ig,in  a  Collecrion  whose  classification  dominates 
their  clearance,  but  again  this  is  likely  to  be  limited  in  an  implementation  to  deleting  at  their 
level. 

Users  can  observe  facts  which  are  in  a  Collection  Object  only  if  its  classification  is  dominated 
by  their  clearance. 

A  high  user  cannot  update  a  low  fact,  but  Polyinstantiating  databases  generally  change  such 
requests  into  inserts  at  the  higher  level.  The  low  Collection  is  observed,  the  fact  is  modified 
according  to  the  requested  update  and  then  inserted  into  a  collection  whose  classification  is 
that  of  the  user's  clearance.  No  low  Collection  Object  has  been  modified  so  the  operation 
preserves  confidentiality. 

For  example,  suppose  the  database  contained  the  Unclassified  fact  that  "Entemrise  is  carrying 
Bananas  to  EaijjL''.  If  a  Secret  user  were  to  change  the  cargo  to  Missiles,  this  would  be 
translated  into  an  insert  of  the  Secret  fact  "Entemrise  is  carrying  Missiles  to  Earth". 

However,  an  insert  is  not  possible  if  an  appropriate  collection  does  not  exist  to  hold  the  new  fact. 
A  new  Collection  Object  can  only  be  created  by  a  user  whose  clearance  equals  the  classification 
of  the  Schema  Object  This  is  because  the  address  of  the  new  Collection  Object  must  be  written 
into  the  Schema  Object,  which  is  its  parent  in  the  Hierarchy.  This  problem  can  be  overcome  by 
having  a  Schema  Object  per  security  level,  but  in  this  paper  the  simpler  model  will  be  used  as  it 
does  not  materially  affect  how  polyinstantiating  databases  can  be  used  for  deception. 

A  user  who  wishes  to  establish  the  truth  of  a  fact  must  be  able  to  observe  the  appropriate  Schema 
Object  in  order  to  determine  which  Collection  Objects  need  to  be  examined.  If  the  fact  is  found 
then  it  is  true,  but  if  the  fact  is  not  found  it  is  either  false  or  too  highly  classified  for  the  user  to 
see. 

In  general,  some  of  the  facts  described  by  a  schema  will  be  too  highly  classified  for  the  user  to 
see  Thus  it  is  not  possible  to  enforce  integrity  constraints  which  can  only  be  established  by 
examination  of  all  the  facts.  Polyinstantiating  databases  can  therefore  only  enforce 
weakened  forms  of  Entity  Integrity  and  Referential  Integrity  [BumsSO], 

As  an  example,  suppose  that  the  database  contains  two  Schemas,  both  Unclassified.  Tlie  first 
concerns  captains  of  starships  and  says  that  facts  of  the  form  is  the  Captain  of  the  are 
stored.  The  second  Schema  is  about  starships'  destinations,  with  the  facts  having  the  form  is 
going  to  The  actual  facts  about  captains  can  be  either  Unclassified  or  Secret,  because  the 
Schema  refers  to  two  Collection  Objects  with  those  classifications.  Similarly  for  destinations. 
However,  there  are  currently  no  Secret  facts  about  captains.  This  is  shown  in  Figure  3.1.  Each 
box  is  an  Object  and  the  arrows  and  indentation  reflect  the  Hierarchy. 


U  |_  is  the  Captain  of  the  _| 


— >  u 

iKirk  is  the  Captain  of  the  Enterprise  I 

[Kahn  is  the  Captain  of  the  Reliant 

_J 

— >  s 

1  1 

U  L  is  going  to  _ 

1 

- >  U 

Enterorise  is  going  to  Romulus 

- >  S 

Reliant  is  going  to  Eaith 

Figure  3.1:  Two  Schemas  each  with  two  Collections. 
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Now  suppose  that  a  Secret  user  mshes  to  change  the  destination  of  the  Enterprise  to  Vulcan.  The 
user  can  observe  the  fact  that  Enterprise  is  currently  heading  for  Romulus,  because  the 
Collection  is  Unclassified,  but  is  prevented  from  altering  it  because  this  would  be  a  write  down. 
However,  the  polyinstantiating  database  treats  the  user's  update  as  a  request  to  insert  a  new 
fact  at  the  higher  level.  Thus  a  new  Secret  fact  is  placed  in  the  Secret  Collection.  Figure  3.2 
shows  the  position  after  this  update 


U  |_is  the  Captain  of  the  J 

- 1  u 

Kirk  is  the  Captain  of  the  Entemrise 

Kahn  is  the  Captain  of  the  Reliant 

— >  s 

U  Lis  going  to  _  I 

— »  u 

Entemrise  is  going  to  Romulus 

— >  s 

Reliant  is  going  to  Earth 

Entemrise  is  going  to  Sukan 

Figure  3.2:  After  updating  Enterprise's  destination. 

Note  that  the  original  fact,  that  Enterprise  is  going  to  Romulus,  still  exists.  It  is  visible  to 
UncIassiHed  users,  who  are  unaware  that  any  change  has  been  made.  Secret  users  can  observe 
botli  the  original  fact  and  the  new  one. 

It  was  the  intention  that  ships  have  unique  destinations,  thus  this  example  database  has  lost  its 
integrity.  If  the  user  had  logged  in  at  Unclassified  and  deleted  the  fact  that  "Enterprise  is 
going  to  Romulus"  and  then  logged  in  at  Secret  and  inserted  "Enterprise  is  going  w  Vulcan", 
integrity  would  have  been  preserved.  However,  a  low  user  could  always  insert  contradictory 
information  without  knowing  it. 

Thus  with  Polyinstantiation,  integrity  cannot  be  enforced  except  by  careful  design  of  the 
application  (Bums90).  However,  this  detracts  from  the  benefit  of  using  a  DBMS. 

33  View  Based  Classification 

A  lesser  known  alternative  to  Polyinstantiation  for  enforcing  confidentiality  in  databases  is 
the  use  of  View  Based  Classifications  [WiIson881  [Knode88].  In  this  model  there  are  Schema 
Objects  and  Value  Objects.  A  Schema  Object  describes  a  class  of  facts,  such  as  _is  going  to_, 
and  gives  all  possible  facts,  whether  they  are  true  or  not.  With  each  possible  fact  is  kept  the 
address  of  the  Value  Object  which  records  whether  the  fact  actually  is  true  or  not. 

In  relational  terms,  a  view  is  a  description  of  all  possible  tuples  that  could  occur  in  the  view, 
along  with  a  note  of  which  tuples  are  currently  in  the  view.  A  tuple  may  only  be  inserted  into  a 
view  if  it  is  one  of  the  possible  tuples,  \t%en  views  are  used  to  classify  information,  a 
classification  is  attached  to  each  possible  tuple  in  the  view  and  this  is  the  classification  of  the 
tuple  if  it  becomes  part  of  the  view. 

In  the  model,  the  Schema  Object  contains  a  description  of  a  view,  by  enumerating  all  the 
possible  facts.  However,  in  practice  the  view  will  he  described  algorithmically  and  the 
true/false  values  will  be  represented  by  storing  the  facts  corresponding  to  the  true  values.  In 
order  to  reduce  the  amount  of  trusted  code  required,  systems  using  this  technique  only  allow 
simple  view  definitions  [Garvey88],  but  the  model  describes  the  general  situation. 

When  a  new  class  of  facts  is  introduced,  all  the  possible  facts  are  calculated  and  a  description 
is  placed  in  a  new  Schema  Object.  For  each  possible  fact,  a  new  Value  Object  is  created  and  is 
a.ssociated  with  the  possible  fact.  The  creation  of  all  these  Objects  mast  be  controlled,  perhaps 
using  the  Hierarchy,  in  order  to  avoid  a  covert  channel. 
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The  Value  Objects  are  given  a  classiGcation  which  is  appropriate  for  the  fact  if  it  were  true. 
This  may  be  higher  than  the  clearance  of  the  user  who  is  creating  it  The  initial  value  of  the 
fact  is  set  as  appropriate,  though  obviously  this  cannot  be  with  a  value  of  true  if  the 
classification  is  higher  than  the  clearance  of  the  user,  unless  such  deliberate 
overclassification  is  required. 

The  classification  of  a  fact  may  depend  on  information  other  than  its  own  value,  such  as  the 
truth  of  other  facts.  Thus  it  is  possible  that  the  Schema  may  refer  to  several  Value  Objects  for  the 
same  possible  fact.  Integrity  constraints  will  usually  ensure  that  only  one  of  these  has  the 
value  true. 

A  new  fact  is  added  to  the  database  by  changing  the  appropriate  Value  to  true.  In  order  to  do  this 
the  user's  clearance  must  be  dominated  by  the  classihcation  of  the  Value  Object,  to  avoid  a  flow 
down,  though  usually  the  user's  clearance  and  the  classification  will  be  equal.  Note  that  new 
Objects  are  created  only  when  new  kinds  of  fact  are  introduced,  rather  than  when  possible  facts 
are  made  true.  Thus  no  covert  channel  arises  through  inserting  new  facts.  Deleting  facts  is 
similar. 


Updating  involves  changing  one  Value  Object  to  false  and  another  to  true.  Since  the  user's 
clearance  must  be  dominated  by  the  classiHcations  of  both  Value  Objects  in  order  for  them  to  be 
altered,  it  is  generally  the  case  chat  a  user  may  only  update  a  fact  "at  their  clearance". 
However,  as  noted  by  [GarveySS],  it  is  possible  for  the  database  to  "polyinstantiate"  by 
converting  an  update  of  a  low  fact  into  an  insert  of  a  high  fact. 

A  user  who  wishes  to  establish  the  truth  of  a  fact  searches  the  appropriate  Schema  Object  for  a 
description  of  the  fact  of  interest.  The  corresponding  Value  Object  is  then  examined  to  find  the 
answer.  If  the  user  can  observe  the  corresponding  Value  Object,  then  the  answer  can  be 
determined  as  true  or  false.  However,  if  the  user's  clearance  does  not  dominate  the 
classification  of  the  Value  Object  the  answer  cannot  be  determined. 


Generally,  integrity  constraints  can  be  applied  to  ensure  that  those  facts  which  are  flagged  as 
true  form  a  consistent  picture.  Users  may  only  modify  the  database  if  they,  or  the  DBMS  on 
their  behalf,  can  determine  that  the  integrity  constraints  are  still  met.  The  proposals  in 
[WilsonSS]  and  [KnodsSSJ  ensure  this  is  possible  in  certain  important  cases  by  restricting  each 
fact  to  having  at  most  one  classification. 


U 


Kui  is  the  Captain  of  the  Enterprise 
Kids  is  the  Captain  of  the  Enterprise 
Kirk  is  the  Captain  of  the  Constitution 
Kahn  is  the  Captain  of  the  Reliant 


U 


Enterprise  is  going  to  Romulus 
Enterprise  is  going  to  Viilfan 
Enterprise  is  going  to  Earth 
Eeliant  is  going  to  Vulcan 


U 

S  ^1^1 

u  i 

U  [tme  I 


Figure  3.3:  Two  classes  of  fact  each  with  four  possibilities. 


Now  consider  the  example,  shown  in  Figure  3.3,  where  the  database  contains  two  Unclassified 
facts.  There  are  actually  two  classes  of  fact,  described  by  two  Schema  Objects.  Each  describes 
four  possible  facts  and  so  addresses  four  Value  Objects  of  varying  classification.  Note  that  the 
example  views  do  not  admit  all  possible  combinations  of  elements,  so  for  some  unspecified 
reason  it  is  not  possible  for  Kahn  to  be  the  Captain  of  the  Enterprise. 


Assume  that  Entity  Integrity  is  in  force  for  both  schemas,  that  is  a  Ship  may  only  have  one 
destination  and  that  a  Captain  can  only  be  in  charge  of  one  Ship.  Now  consider  the  example 
where  a  Secret  user  attempts  to  change  the  destination  of  the  Enterprise  from  Romulus  to 
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Vulcan.  Tlie  nser  is  enable  to  eba:^  the  Valce  Oigeel  cf  "EoteipHse  is  gsis;  ta  Bcsslns"  ta 
false,  because  this  is  an  Undasafied  Object  and  sa  the  operatica  vacH  cossStste  a  ilsv  dasn. 
However,  unless  this  fact  is  mailced  as  false,  it  is  nt  possible  to  change  &e  desiinalisn  ta 
Vulcan  because  of  Enti^  Integrity. 

One  way  out  of  this  impasse  is  to  use  polyinstantiarioa.  This  allows  the  Secret  user  ta  add  a  sew 
destination  without  altering  the  origb^al.  However,  this  does  not  preserve  Entify  Integri^, 
dnee  the  ship  ends  with  two  desHnations. 

The  only  method  for  changing  &om  an  Undasdfied  destination  ta  a  Secret  one  is  for  an 
Unclassified  user  to  change  the  Value  Object  of  the  orignal  destination  to  false  and  a  Secret 
user  to  add  the  new  destination.  Obviously  if  this  reipiires  a  real  user  to  log  in  at  Undasafied 
and  then  to  diange  to  Secret  this  will  be  inconvenient,  but  tbe  use  of  a  mnlti-Ievd  secure 
worhstation,  sudi  as  [CnmmingsSTl,  would  undoubtedly  improve  the  user  inteifac& 

However,  the  need  to  *log  in*  tmee  raises  a  more  serious  integrity  problem  in  some  cases. 
Suppose  the  database  has  an  integrity  constraint  whidi  inasts  that  a  ship  always  has  exacts 
one  destination.  The  problem  is  that,  because  two  transactions  are  required  to  melee  the  update 
an  illegal  state,  in  which  the  ship  has  either  no  destination  or  two  destinations,  becomes  visible 
to  others. 

A  potential  solution  to  these  problems  is  to  use  high  water  marks,  or  floating  labels 
[Woodwards?],  to  allow  the  user's  clearance  to  rise  during  a  transaction.  At  the  start  of  the 
transaction  the  user's  clearance  is  set  to  Unclassified.  The  usej  sets  *Enteiprise  is  going  to 
Romulus"  to  false.  The  classification  is  now  raised  to  Secret  and  the  user  decides  on  the  new 
destination,  Vulcan,  and  "Enterprise  is  going  to  Vulcan*  is  set  to  true.  Once  the  update  has 
completed,  the  changes  can  be  committed.  This  means  that  no  other  user  sees  the  database  in 
an  inconsistent  state,  that  is  the  Enterprise  always  has  exactly  one  destination. 

However,  this  solution  is  not  secure  because  of  the  nature  of  transactions.  A  user  can  propose  to 
modiiy  low  data  and  then  decide  whether  to  commit  or  roll  back  tbe  transaction  on  the  ^is  of 
high  data.  This  causes  a  downward  flow  because  the  changes  to  low  data  depend  on  high  data. 
Thus  high  water  marks  within  a  transaction  are  insecure. 

A  more  subtle  problem  is  illustrated  by  this  example.  If  the  constraint  that  a  ship  always  has 
one  destination  is  enforced,  once  the  update  has  been  completed  an  Unclassified  user  can  infer 
that  Enterprise  is  heading  to  Vulcan.  This  is  because  the  Unclassified  user  is  able  to  see  that  it 
IS  heading  nowhere  else.  While  this  problem  can  be  avoided  by  suitable  data  design  [LuntS9],  it 
does  mean  that  any  schemas  designed  for  such  a  secure  database  will  have  to  be  evaluated  in 
some  way  to  determine  that  they  do  not  admit  such  an  inference  problem.  The  need  for  such 
scrutiny  was  recognised  by  [WilsonSS],  but  such  inferences  are  actually  a  potential  problem  in 
ail  secure  systems,  though  they  become  more  evident  in  databases  because  the  data  has  more 
structure  and  classifications  are  applied  with  a  finer  grain  of  protection. 

33  Insert  Low  Approach 

Another  alternative  to  Polyuistantiation  is  the  Insert  Low  approach  (WisemanSOal.  In  this 
model  there  is  an  Object  for  each  class  of  fact,  which  contains  schema  information,  and  one  for 
each  true  fact.  The  Schema  Objects  contain  the  addresses  of  the  Fact  Objects,  which  are  their 
subordinates  in  the  Hierarchy.  The  Fact  Objects  referred  to  by  a  Schema  Object  may  have 
various  classifications,  ail  of  which  dominate  the  classification  of  the  Schema  Object  When  a 
new  Schema  Object  is  created,  the  Hierarchy,  or  some  unspecified  control,  is  used  to  ensure 
that  no  covert  channel  is  admitted. 

In  relational  terms,  the  Schema  Object  corresponds  to  a  table  and  the  Fact  Objects  to  a  row  or 
field,  depending  on  the  granularity  of  labelling.  The  Hierarchy  ensures  that  users  can  only 
detect  the  existence  of  fields  and  rows  if  their  clearance  allows  them  to  "pass  through"  the 
table.  If  fields  are  individually  classified,  a  row  is  made  up  of  several  Fact  Objects,  each 
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dessssi:  ih>  Tt32!jsa^i9 1  et’scd  ese  fsSiset  cf  the  eoJcsss.  Tbss  there  sn  geserzDjr  i29re 
Fseis  per  T3»  thza  &eie  axe  cahsns. 

’When  anep&et  is  inserted  aneg  Feet  Oigeet  is  ereate3,«s«tcberSaate  to  the  SdsesaOtseet, 
and  tee  salce  cf  tbe  fart  is  place' in  iL  In  adStioa,  the  address  rfthe  neg  Fart  Best  be 

placed  in  the  Sdiena  Object,  tbns  the  tisera  clearance  enst  eqsal  the  dassSfication  of  the 
Sdieaa  Ozgeci.  Hogever,  the  new  tart  027  bare  a  greater  dassrSca&in,  tboai^  the  user  woold 
then  be  enable  to  see  gbat  they  hare  fnserttd. 

So  only  log  csers  can  insert,  hence  the  name  of  the  approadi.  Wb3e  this  laay  sound 
ezcesrtvely  restrictive  it  artn^ly  places  no  more  constraints  on  the  users  other  than  are 
required  tor  the  enforcement  of  both  confidentialify  and  integrity. 

Similarly,  to  ddete  a  fart  it  is  necessary  to  remove  its  address  from  the  Schema  Oigect.  This 
means  that  only  users  whose  clearance  equals  the  classification  of  the  Sdicma  Olgect  can 
ddete  tarts. 

To  update  a  fart,  a  user  must  first  find  the  appropriate  Fart  Object  and  modity  it  Thus  thmr 
clearance  must  ^  dominated  by  the  classificatian  of  the  Fart  Object  However,  the  user  will 
normally  observe  something  of  the  Fart  Otgert's  original  value,  since  pure  writes  are  difncult 
to  achieve  in  practice,  and  so  the  clearance  vrill  usually  equal  fire  classification. 

A  user  who  wishes  to  establish  the  truth  of  a  tart  must  examine  all  the  Fart  Objects  referred  to  I7 
the  appropriate  Schema  Olgect  If  all  the  necessary  Fact  Objects  can  be  observed,  the  user 
obtains  a  complete  answer.  However,  if  some  have  classifications  which  are  not  dominated  I7 
the  user  s  clearance,  the  answer  may  not  be  complete. 

Integrity  constraints  can  be  applied  generally,  but  tisers  may  only  modify  the  database  if  they 
(or  rather  the  DBMS  on  their  behalO  can  establish  that  the  constraints  are  not  violated. 

For  example,  in  order  to  determine  that  Entity  Integrity  is  preserved  when  inserting  a  new 
fact,  it  is  necessary  to  be  able  to  examine  all  existingfacts  to  rteck  that  the  'key'  is  not  already 
present.  The  user's  clearance  must  equal  the  classification  of  the  Schema  Object  to  be  able  to 
insert  and  so  if  any  Fact  Object  has  a  classification  higher  than  that  of  the  Schema  Object  the 
user  will  be  unable  to  confirm  that  Entity  Integrity  is  upheld^.  Note  that  a  user  with  higher 
clearances  could  check  for  Enfity  Integrity  but  is  prevented  from  inserting  because  of  the 
'existence'  covert  channel.  That  is,  unless  the  ley'  facts  all  have  classifications  equal  to  the 
Schema  Olgect's  classification,  new  facts  cannot  be  inserted. 

So  although  it  is  not  strictly  necessary  for  keys  to  be  single  level,  on  the  whole  they  will  be  to 
allow  new  facts  to  be  inserted.  This  introduces  a  potential  availability  problem,  but  it  is  easily 
controlled  by  applying  integrity  constraints  to  the  classifications  of  the  Facts. 

Now  consider  the  example  of  a  user  wishing  to  change  the  Enterprise's  destination  from 
Romulus  to  Vulcan.  The  fact  that  the  destination  is  to  change  is  unclassified,  while  the  fact  that 
the  destination  is  to  be  Vulcan  is  Secret  Obviously  the  user  is  cleared  to  at  least  Secret 
Initially  the  database  contains  two  Schemas,  each  referring  to  one  Fact  This  is  shown  in 
Figure  3.4. 

u  E  is  the  Captain  of  theZI - *  U  |Kirk  is  the  Captain  of  the  Entemn'se  | 

U  |_  is  going  to  _  |  — »  U  lEnkrprist  is  going  to  Romulus  I 

Figure  3.4:  Two  Schemas  with  two  Facts. 


^Rejecting  an  insert  for  this  reason  does  not  lead  to  a  covert  channel  because  it  is  only  the 
value  of  the  fact  that  is  highly  classified,  not  its  existence. 


U 


So  iht  Secnt  jser  otsis  io  eizngs  the  detehete  ss  seen  b^r  Vn:3essiSed  csers.  To  sroid 
djTO'fi-ardfloiFstaecscringst  login  at  IfodassiSed  and  ddeie  the  that  the  Enterprise  is 
gES^  to  Eoaniss.  Kelt  a  ne?  Fact  OJ^eot  is  created  whi^  is  dassiSed  Seaat,  eren  thoaj^  the 
csei's  eerrent  dearanee  is  Unclassified.  Into  this  near  Fact  Oloect  is  placed  some 
Dhclassified  inforzeatioa,  naoefy  that  Enterprise  is  gang  senrenhere  (eSeebvefy  a  nnll). 
The  user  near  kgs  cot  and  bade  in  at  Secret  and  updates  the  tact  to  record  fire  tree  destination, 
Vnican. 

However,  suppose  there  is  cn  integrify  constraint  which  innsts  that  ships  alarqrs  have  a 
desiznaticn.  The  sohiticnjnst  described  albnrs  the  Enterprise  to  have  a  null  destinaticai  for  a 
short  tizne,  contrary  to  the  int^fy  constraint.  An  alternative  epprcacb  avoids  this  prchlem. 
The  user  logs  in  at  Unclassified  and  tqigrades  the  Fact  Oljectarhi^  records  the  destination  of 
the  Enterprise.  Note  that  changing  the  classification  of  a  Fact  Oijeet  is  secure  if  the  user's 
clearance  eqnals  the  Sdrema  Cqeot's  dasriScafion,  becanse  the  Hierarthy  hides  the  diange 
fi-cin  users  with  lower  dearances.  Figure  3.5  dtows  the  database  afier  this  actron  has  been 
committed. 


_is  the  Captain  of  the. 

— »  U 

_is  going  to_ 

— »  S 

figure  3.5:  After  upgrading  the  Fact. 


Once  the  Fact  Oi^ect  is  classified  Secret,  the  user  can  log  in  at  Secret  and  update  its  contents  to 
the  desired  value.  The  final  result  is  diown  in  Figure  3.6. 


_  is  the  Captain  of  the  _ 

— »  U 

.is  going  to _ 

— I  S 

Figure  3.S:  After  updating  the  Fact 


With  the  Insert  Low  approach  the  opposite  is  also  possible.  An  Unclassified  user  may  change  a 
Secret  destination  to  an  Unclassified  one,  assuming  that  this  is  reasonable  from  an  integrity 
point  of  viev;,  as  follows. 

The  Schema  objects  will,  in  practice,  contain  information  about  how  facts  like  "Enterprise  is 
going  somewhere"  and  "Enterprise  is  going  to  Vulcan"  are  related.  This  would  allow  an 
Unclassified  user  to  identify  which  Fact  Object  contains  the  Enterprise's  destination,  though 
without  revealing  the  contents  of  the  Fact  Object  The  Unclassified  user  may  change  the 
classification  of  the  Fact  Object  to  Unclassified  as  long  as  they  completely  overwrite  the 
original  information'.  There  is  no  covert  channel  because  the  Hierarchy  stops  any  lower  user 
from  seeing  the  changes. 

Figure  3.7  shows  the  state  after  an  Unclassified  user  has  changed  the  destination  of  the 
Enterprise  to  Earth.  Note  that  this  is  secure  since  the  Unclassified  user  learns  nothing  of  its 
previous  destination  and  that  the  Hierarchy  ensures  no  user  with  lower  clearances  sees  the 
classification  change.  Note  that  this  form  of  "pure  write"  can  be  implemented  since  a  complete 
Object  is  overwritten. 


U 

.  is  the  Captain  of  the  . 

- » 

u 

Kirk  is  the  Captain  of  the  Enterprise 

U 

_  18  goin^  to  _ 

— ► 

u 

Enterprise  is  going  to  Efltlh 

Figure  3.7:  After  updating  the  Fact  to  a  lower  value. 


'A  low  user  overwriting  high  data  is  not  a  confidentiality  problem  ([Bell74]  allows  it!).  Like 
any  alteration  of  the  database,  even  high  users  overwriting  high  data,  it  is  likely  that  it  would 
be  governed  by  integrity  controls,  such  as  described  in  (WisemanSOb]. 


12 


TbEse  meihods  of  updating  net  only  smi  pobinstsntiation  bat  preserve  integiify  censtrzints 
fiideb  insist  that  faets  cf  a  certain  ferm  alte^-^s  exist.  Ine  cost  cf  avoiding  polyinstantiation  is 
that  the  user  most  log  in  and  ont,  thon^  this  sronid  be  alleviated  by  ntili^g  a  rnnlti-levd 
woihstation,  bat  the  benefit  is  that  the  database's  integi%  is  preserved  and  that  this  can  be 
enforced  by  the  DBMS. 

4,Ileception  veith  bitggritv 

In  this  section  the  three  techniques  for  database  seauify  are  examined  srith  r^ard  their 
suitability  for  applications  that  require  some  users  to  be  deceived.  Hie  important  issue  is  how 
well  they  enforce  the  integrity  of  the  deception.  If  int^rity  cannot  be  preserved,  users  who 
should  see  the  truth  may  become  contused  or  the  users  w;)o  are  suppos^  to  be  deceived,  but 
without  knowing  it,  may  detect  inconsistendes  whidi  reveal  the  existence  of  the  deception. 

4.1  DenvingEristenoe 

Denying  the  existence  of  a  class  of  facts  is  relatively  strai^tforward  with  any  of  the  three 
techniques.  Essentially  the  existence  of  the  sdiema  information  which  describes  the  sensitive 
facts  must  be  hidden  from  the  users  who  must  not  know  such  facts  exist. 

In  all  three  approaches,  the  Siinsitive  schema  information  is  held  inside  Schema  Objects, 
though  these  differ  in  format  for  each  method.  Only  users  whose  clearance  dominates  the 
classification  of  a  Schema  can  otserve  details  of  the  schema.  Without  this  infonaation  a  user 
is  unable  to  ascertain  whether  the  information  being  hidden  is  of  interest.  So  in  most  cases 
simply  classifying  the  Schema  Objects  appropriately  is  sufficient  to  protect  sensitive 
information. 

However,  in  extreme  cases  it  is  necessary  for  the  database  to  be  constructed  so  that  it  does  not 
reveal  everything  to  some  of  its  users,  and  yet  they  remain  convinced  that  nothing  is  being 
withheld  from  them.  A  user  who  finds  that  they  are  unable  to  observe  a  Schema  Object  may  be 
alerted  to  the  fact  that  the  database  is  not  telling  them  the  whole  truth.  Thus  it  is  sometimes 
necessary  to  hide  the  existence  of  certain  Schema  Objects,  not  just  their  contents. 

This,  however,  is  the  purpose  of  the  Hierarchy.  In  the  discussions  about  each  approach,  it  was 
assumed  that  some  control  was  being  applied  to  prevent  the  creation  of  new  Schema  Objects 
from  being  used  as  a  covert  channel.  Essentially  this  will  be  the  use  of  either  a  special  function 
which  is  trusted  to  not  exploit  the  channel,  or  some  extra  level  of  Hierarchy  which  will  hide  the 
creation  from  users  whose  clearance  does  not  dominate  the  clearance  of  the  creator. 

This  extra  level  of  Hierarchy  can  be  used  to  ensure  that  users  with  insufficient  clearances 
cannot  detect  the  existence  of  schemas  which  they  must  not  know  exist.  However,  this  is  not  a 
complete  solution  because  these  users  will  discover  that  there  are  things  they  are  not  allowed  to 
see,  although  they  will  not  necessarily  know  that  they  are  schemas.  Unfortunately,  Bell- 
LaPadula  style  models  do  not  lie  about  the  existence  of  Objects  (strictly,  whether  they  are 
activated  or  not)  and  so  the  problem  cannot  be  fixed  within  the  simple  modelling  framework 
chosen  here. 

The  requirement  is  for  an  Object  whose  existence  cannot  be  detected  by  users  of  lower 
clearance.  Thus,  a  user  should  receive  the  same  error  message  if  they  attempt  to  access  one  of 
these  hidden  Obj“cts  as  if  they  attempt  to  access  a  non-existent  Object  The  requirement  can  be 
implemented,  though  care  must  be  taken  to  avoid  covert  timing  channels  which  inadvertently 
reveal  the  two  reasons  for  the  same  reply.  However,  in  the  absence  of  a  suitable  model  this 
paper  will  leave  the  problem  to  future  research  and  just  indicate  that  existence  needs  to  be 
hidden  by  drawing  the  Object's  classification  in  outline  format,  eg.  C. 

To  implement  the  example  of  section  2  2,  two  Schema  Objects  are  required  Figures  4  1, 4.2  and 
4.3  show  this  for  each  of  the  three  techniques  One  Schema  lists  those  torpedoes  for  which  the 
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sj'stem  records  radiation  information,  the  other  records  the  actnal  radiation  on^mt  for  each  of 
these  torpedoes.  The  existence  of  both  these  Schemas  is  hidden  inside  a  ‘directory*  of 
Confidential  schemas,  thns  an  Unclassified  user  cannot  d  tect  that  there  is  any  information 
whidi  they  are  not  entitled  to  see.  Confidential  users  will  be  ^le  to  discover  that  two  schemas 
exist,  but  win  be  unable  to  detennine  what  they  describe. 


Figure  4.1:  Denying  the  existence  of  information  using  polyinstantiation. 


Note  that  if  the  Confidential  'directoiy'  was  not  hidden  from  lower  users,  they  would  be  able  to 
discover  that  an  Object  .'xists  which  they  cannot  observe.  This  is  not  usually  a  problem,  but  in 
this  example  the  appii  ition  wishes  Unclassified  users  to  believe  there  is  nothing  they  cannot 
sec. 


Using  polyinstantiation  each  Schema  refers  to  a  number  of  Collections,  in  this  case  two.  Facts 
are  stored  in  the  Collection  of  the  appropriate  classification. 

Using  view  based  classifications,  each  possible  fact  is  listed  in  the  Schema.  Associated  with 
each  possible  fact  is  a  Value  Object  which  indicates  whether  the  fact  is  true  or  not.  The 
classification  of  the  Value  Object  is  what  the  classification  of  the  fact  would  be  if  it  were  true. 


ISchemas  whose  existence  is  Confidential 


S  there  is  data  on  the  MhS  torpedo 
there  is  data  on  the  Mli4  torpedo 


T  lltite  I 
S  Itnic  I 


S  Mk4  torpedo  emits  94.8  femtoUrgs  per  second 
Ml(4  torpedo  emits  86.S  femtoUrgs  per  second 
Mk3  torpedo  emits  42.1  femtoUrgs  per  second 
hfk3  torpedo  emits  78.3  femtoUrgs  per  second 


S  Itruc  i 
T  [f|l»ej 
T  fal8c  I 
T  i 


Figure  4.2:  Denying  the  existence  of  information  using  views. 


Using  the  Insert  Low  Approach,  the  facts  are  each  stored  in  separate  Fact  Objects,  which  are 
referred  to  by  the  Schema  Object.  The  fact's  classification  is  that  of  the  Fact  Object  which  holds 
it. 
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C  ISehemas  yhose  existence  is  Confidential  | 


- »  S  jlhere  is  data  on  the  _  torpedo  1 _ 

— >  t  .Jiere  is  data  on  the  hik4  torpedo  I 

- »  S  Ltoipedo  emits  _fenitoUrgs  per  second  | 

- »  T  |^Tk4  torpedo  emits  94.8  femtoUrgs  per  second  I 

Figure  4^:  Denying  the  existence  of  information  using  insert  low. 

So  the  abilify  of  an  application  to  deny  the  existence  of  information  is  independent  of  the  chosen 
database  securify  technique.  The  problem  is  solved  by  tising  the  Hierardiy  to  bide  the  existence 
of  schemas,  though  the  notion  of  Hierarchy  must  be  extended  slightly  to  allow  the  existence  of 
the  hiding  mechanism  to  be  hidden. 

42COVCT  Stories 

For  a  cover  story  to  be  effective,  users  who  are  being  misled  must  not  realise  that  the  same  kind 
of  information  is  also  held  at  a  higher  level,  thus  the  techniques  discussed  above  for  denying 
the  existence  of  information  are  necessary.  Also,  high  users  must  be  able  to  invent  the  cover 
story  and  enter  this  with  a  low  classification.  This  necessitates  the  user  logging  in  and  out  or 
the  use  of  a  multi-level  workstation. 


U  ISehemas  whose  existence  is  Unclassified  | 


- >  U  |_  is  going  to  _  I 

- »  U  |Constitution  is  going  to  Romulus  ~] 

— >  U  |_  is  going  to  _  to  _  I 

- »  U  [Constitution  is  going  to  Romulus  to  deliver  aid~] 

C  ISehemas  whose  existence  is  Confidential  | 


- >  C 


L  is  going  to 

-to.  1 

- >  S 

Constitution  is  poing  to  Romulus  to  invade 

- >  T 

Constitution  is  Mine  to  Romulus  to  standbv 

Figure  4.4;  The  problem  with  polyinstantiation  for  cover  stories. 

If  these  points  are  covered,  any  of  the  three  techniques  can  be  used  to  provide  cover  stories  This 
is  possible  because  each  can  provide  the  ability  to  lie  about  the  existence  of  information. 

Using  polyinstantiation,  the  main  difficulty  is  not  allowing  cover  stories,  but  preventing 
spurious  ones  from  being  created.  Consider  again  the  example  shown  in  Figure  2.3,  but 
suppose  a  Top  Secret  user  now  wishes  to  stand  down  the  invasion  force.  The  user  is  able  to 
update  the  mission  of  the  Constitution  to  standby,  however,  this  change  is  not  seen  by  any  Secret 
user.  This  leads  to  disaster.  Obviously  the  correct  course  of  action  for  the  Top  Secret  user  is  to 
log  in  at  Secret  and  make  the  change,  but  the  absence  of  any  integrity  check  for  duplicate 
missions  means  this  is  not  enforced.  Effectively  a  new  cover  story  has  been  invented  when  one 
IS  not  needed,  as  shown  in  Figure  4.4. 
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is  going  to  Romuias  ta  invade 
ICon^itofinn  fa  going  to  RoTnoius  to 

Figure  4.5:  Cover  atones  using  views. 


S  l<n»  I 


S  li«i«e  I 


View  based  classiGcations  can  be  used  to  provide  cover  stories,  as  shown  in  Figure  4.5.  Two 
mission  schemas  arc  created,  one  for  the  cover  story  and  one  for  the  real  mission.  The  real 
mission  is  hidden  from  Unclassified  users,  while  those  with  high  clearances  can  see  both  but 
know  the  difference  between  the  two.  The  view  gives  the  classification  of  Constitution  being  put 
on  standby  as  Secret,  therefore  a  Top  Secret  user  is  prevented  from  updating  it  directly.  By 
logging  in  at  Secret  tlie  user  could  set  the  mission  to  standby,  but  integrity  constraints  would 
prevent  this  if  the  ConsUtution  is  already  on  an  invasion  mission,  as  in  this  example. 


Schemas  whose  existence  is  Unclassified 


Figure  4.6;  Cover  stories  using  insert  low. 

The  method  for  providing  cover  stories  with  the  insert  low  approach  is  similar  to  that  with  view 
based  classiGcations,  two  schemas  are  used,  one  for  the  cover  story  and  one  for  reality.  Figure 
4.6  shows  the  example.  The  Top  Secret  user  cannot  change  the  mission  because  the  Fact  Object 
is  Secret  and  this  would  constitute  a  downward  Gow.  Once  the  user  logs  in  at  the  Secret  level  the 
update  and  integrity  checks  present  no  problem. 

So  any  of  the  three  techniques  provide  the  ability  to  invent  cover  stories.  With 
Polyinstantiation  cover  stories  can  be  invented  "on  the  fly",  while  the  other  two  techniques 
require  design  time  decisions  to  build  the  ability  to  have  cover  stories  into  the  schemas. 
Polyinstantiation  therefore  has  the  advantage  that  a  cover  story  can  be  inserted  without  prior 
thought,  but  this  is  also  its  weakness  because  there  is  no  way  of  preventing  the  creation  of 
spurious  cover  stories. 


If  low  information  is  to  be  altered  by  high  users,  and  these  changes  are  to  be  kept  from  low 
users,  then  the  problem  is  similar  to  that  for  cover  stories.  However,  the  difference  is  that  the 


low  information  is  inserted  low  users,  which  presents  no  problem.  When  the  high  users 
wish  to  update  the  information  the  original  is  left  unaltered,  and  again  this  presents  no  real 
problem.  Thus  any  of  the  three  techniques  for  database  security  provide  the  ability  to  keep 
changes  secret. 

In  fact  the  only  diiftculty  is  to  ensure  that  the  high  user  can  refer  to  the  correct  information 
without  confusion.  Initially  the  low  information  is  correct  and  this  is  what  the  high  user  will 
want  to  see.  However,  once  this  is  superseded  by  high  information,  the  high  users  will 
ordinarily  wish  to  see  the  high  information,  though  they  may  explicitly  ask  for  the 
information  as  seen  by  low  users. 

So  the  solution  is  to  use  two  schemas,  one  for  the  low  version  of  the  information  and  one  for  the 
high  version  when  this  is  different  Low  users  have  access  to  the  low  schema  and  may  be 
prevented  from  detecting  the  high  schema.  High  users  have  access  to  both  schemas,  but  really 
wish  they  could  see  them  as  one.  This  can  be  achieved  using  a  view  mechanism,  but  the  view 
definition  will  be  complex  and  implementations  usually  insist  that  such  views  are  read-only 
nS089]. 

Actually,  all  that  is  required  is  a  special  kind  of  project  view,  which  is  relatively  simple  to 
implement  This  yields  the  high  version  of  a  fact  if  it  exists,  otherwise  it  yields  the  low 
version.  When  such  a  view  is  updated,  the  high  version  is  updated,  unless  it  does  not  exist  in 
which  case  a  high  insert  is  performed.  Unfortunately,  such  special  purpose  requirements  are 
unlikely  to  be  standardised,  and  so  further  research  is  necessary  to  investigate  how  updatable 
views  can  be  defined  in  general. 

5.  Conclusions 

In  most  secure  databases  classifying  sensitive  information  is  enough  of  a  control,  since  the 
users  will  not  be  surprised  to  discover  that  there  is  information  which  is  too  highly  classified 
for  them  to  see.  However,  there  are  extreme  cases  where  the  existence  of  such  information  must 
be  hidden  Further,  the  database  may  be  required  to  deceive  some  users,  by  presenting  them 
with  a  "cover  story"  rather  than  the  truth.  Similarly,  the  database  may  be  required  to  hide 
changes  made  to  some  information  from  certain  users. 

Of  the  three  techniques  for  achieving  security  in  databases  described  in  this  paper. 
Polyinstantiation  is  the  most  widely  known  technique,  but  View  Based  Classifications  and  the 
Insert  Low  Approach  are  viable  alternatives.  Any  of  these  three  techniques  could  be  used  in  a 
DBMS  which  supports  databases  that  deceive  their  users.  However,  the  requirement  is  not 
simply  for  a  database  that  deceives,  but  for  one  where  the  deception  is  controllable. 

This  is  where  Polyinstantiation  is  weakest.  Its  inability  to  enforce  even  relatively  simple 
integrity  constraints  means  that  cover  stories  can  occur  unintentionally.  The  resulting 
confusion  could  have  serious  consequences. 

The  two  alternative  approaches  can  both  accommodate  deception  in  databases,  though  in  a 
controlled  way.  They  are  also,  of  course,  able  to  enforce  general  integrity  constraints  even 
when  deception  is  not  required.  As  such,  secure  databases  built  using  these  techniques  are 
likely  to  have  superior  data  integrity  characteristics  to  those  that  use  Polyinstantiation. 

However,  both  View  Based  Classifications  and  the  Insert  Low  Approach  do  require  more 
trusted  code  to  implement  the  DBMS  than  with  Polyinstantiation.  As  such  it  is  more  expensive 
to  achieve  a  DBMS  of  a  given  assurance  using  these  techniques.  However,  applications  which 
use  a  Polyinstantiating  DBMS  may  be  more  expensive  to  produce,  because  it  is  then  up  to  the 
application  to  enforce  integrity. 

In  summary.  Polyinstantiation  is  not  the  only  technique  for  achieving  security  in  databases, 
even  when  the  database  is  required  to  deceive  some  users,  and  the  alternatives  merit  further 
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attention.  Future  research  must  devise  database  design  methods  for  each  database  security 
technique  to  allow  fair  comparisons  to  be  made  as  to  their  effectiveness. 
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